PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 4/USEnet 4.51

Text File | 1988-06-15 | 27.3 KB | 671 lines | [TEXT/ttxt]

18-Apr-88 07:53:13-PDT,28572;000000000000
Return-Path: <[e-mail]>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Mon, 18 Apr 88 07:52:43 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa15649; 18 Apr 88 9:46 EDT
Received: from relay.cs.net by RELAY.CS.NET id aa12401; 18 Apr 88 9:40 EDT
Received: from sdr.slb.com by RELAY.CS.NET id ac12362; 18 Apr 88 9:35 EDT
Date: Mon, 18 Apr 88 09:22 EDT
From: Jeffrey Shulman <[e-mail]>
Subject: Usenet Mac Digest V4 #51
To: [e-mail], [e-mail]
X-VMS-To: in%"[e-mail]",in%"[e-mail]"

Date: Mon 18 Apr 88 09:22:40-GMT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V4 #51
To: Usenet-List: ;
Message-ID: <577358560.0.SHULMAN@SDR>
Mail-System-Version: <VAX-MM(218)+TOPSLIB(129)@SDR>

Usenet Mac Digest     Saturday, April 16, 1988       Volume 4 : Issue 51

Today's Topics:
     Pacer vs. Alisa (A Tale of Two VAX-Mac Systems)
     3D Graphic MANIPULATIONS.....
     How do you count unused master pointers?
     question about fonts
     LightspeedC Vapor Ad (was Re: LSC and CODE resources)
     Re: DAHandler and memory management
     Re: Error Handling and Recovery (long reply)
     Re: LSC and CODE resources
     Re: What hard disks does A/UX support
     Problems with A/UX--NFS locking up (2 messages)
     Re: 3D Graphic MANIPULATIONS.....
     Bibliography support package wanted.
     Enabling my Lisa to run Mac+ software
     Re: Graphic window from MPW tool

----------------------------------------------------------------------

From: [e-mail]
Subject: Pacer vs. Alisa (A Tale of Two VAX-Mac Systems)
Date: 11 Apr 88 20:36:15 GMT
Organization: UCLA Computer Science Department

We are connecting our VAXes to our Macintoshes through the very popular
Kinetics FastPath gateway box. I'm comparing the two popular software
packages made by Alisa Systems and Pacer. We have a cluster of an 11/780
and an 8350, plus a LPS-40 Laser Printer.

Does anyone have any comments about either system? The LPS-40 is an
ethernet based printer; one of our main objectives is to make this
printer available to our Macintoshes.


    Stephen Lui
    UCLA Department of Computer Science and

    System Manager
    Hughes Aircraft Company
    Radar Systems Group

Physical Address:
    Centinela Ave. & Teale St.
    Culver City, CA.
    [phone]

Mailing Address:
    Hughes Aircraft Company
    M/S RC R49 2563
    P.O. Box 92426
    Los Angeles, CA
    90009-2426

    ARPA:  [e-mail]
    UUCP:  ...!{cepu,ihnp4,trwspp,ucbvax}!ucla-cs!lui
    Stephen Lui

    ARPA:  [e-mail]
    UUCP:  ...!{cepu,ihnp4,trwspp,ucbvax}!ucla-cs!lui


------------------------------

From: [e-mail] (Jim Rulla)
Subject: 3D Graphic MANIPULATIONS.....
Date: 11 Apr 88 22:34:18 GMT
Organization: The University of Texas at Austin, Austin, Texas


Netters,

I am trying to simulate the "addition" of solids using computer
graphics; I have eight triangular solids; I want to see what the
resulting figure looks like if I arrange them together according to some
arbitrary scheme. All this has to be done in a 3D space. Any ideas if
MAC3D can do this ? I.E., does MAC3D allow manipualtion of 3D primitives
in a 3D space ? How about some other software which can do this ?
--
Thanks,
Jim


------------------------------

From: [e-mail] (Julian Vrieslander)
Subject: How do you count unused master pointers?
Date: 10 Apr 88 05:36:27 GMT
Organization: Cornell Theory Center, Cornell University, Ithaca NY

The "standard" approach to allocating master pointer blocks is to
(empirically) determine the largest number of handles an application is
likely to need, and then to place enough calls of MoreMasters() in the
initialization code to cover that worst case.  A more sophisticated
approach that I have seen described in a couple of places (including
Scott Knaster's first book) involves periodically counting the number of
unused master pointers.  When you see them running low you call
MoreMasters() again, making sure to do the call when it will not cause
fragmentation (eg. from the event loop, with all segments unlocked).

That sounds like a good idea, but I am not sure how to do it in a way
that will not be broken by future changes to the master pointer format.
Inside Mac says that the unused master pointers are kept in a linked
list, and the address of the first one can be found in the heap zone
header.  But the master pointers themselves are not normal pointers -
the high byte is used for flags, the low 3 bytes for the address.  So it
seems that special code is needed to traverse the list.  Can this be
done in a way that won't fail if the master pointer format changes?  And
how likely is it that the format will change?
--
Julian Vrieslander [phone]
Neurobiology & Behavior, W250 Mudd Hall, Cornell University, Ithaca NY 14853
UUCP: {cmcl2,decvax,rochester,uw-beaver,ihnp4}!cornell!batcomputer!eacj
INTERNET: [e-mail]     BITNET: eacj@CRNLTHRY


------------------------------

From: [e-mail]
Subject: question about fonts
Date: 8 Apr 88 14:17:00 GMT

If anyone can answer the following questions concerning Mac fonts please
send me some email.

I am trying to build a font where the bit image for the font is so large
the that the owtloc variable (word offset to the offset/width table) for
the resource overflows. Is there some way around this on a Mac II?

Also: is it possible to build a font with a size > 127
--
Joe Pickert
Center for Supercomputing Research and Development
University of Illinois
ARPA:   [e-mail]
UseNet: uiucdcs!uicsrd!pickert


------------------------------

From: [e-mail] (Richard Siegel)
Subject: LightspeedC Vapor Ad (was Re: LSC and CODE resources)
Date: 10 Apr 88 18:39:22 GMT
Organization: Carnegie Mellon University


Let me take a second to clear that up now.

It turns out that our ad agency messed up on us and placed that ad in
MacTutor. It was not a corporate decision of Symantec, or of the THINK
Division, nor was it a case of the marketing staff being ahead of the
engineering  staff. It was a screwup, plain and simple. My associates
back in Bedford are pretty frosted at this ad agency, because as you so
accurately point out, it makes us look bad, and it makes people mad.

It's turned out to be a confusing business, and I apologize to all.

[For those if you who came in late, here's the scoop: I understand (I
haven't seen it) that an ad for the new version of LightspeedC appeared
in a recent issue of MacTutor magazine.]

        --Rich


------------------------------

From: [e-mail] (Raymond Lau)
Subject: Re: DAHandler and memory management
Date: 11 Apr 88 03:36:37 GMT
Organization: The Big Electric Cat

I don't know the answer to your question per se....but an idea to
relate.

Recently, while implementing UnStuffIt DA, I needed around 160k in a few
large structures.  (And about 5k in a small one.)

For the large one I stuck to using the MF Temporary Memory allocation
routines.  (WHICH, I might add, are not included in LSC 2.15 glue!) Only
allows for non-relocatable blocks...but...if you need, lock them in
place and dereference them.  (Of course, when through, get rid of them.)

When temp mem. allocation isn't available, I stuck w/NewPtr...  (The DA
was designed to be transient in nature, so I didn't bother w/a
relocatable block.)

For the 5k structure, a simple NewPtr...  Under MF, if not enough
memory, I get the appropriate error msg. from the allocation routines.
(I haven't been able to generate a case where the NewPtr of 5k fails for
sure and the rest succeeds, so I don't know...  I'd check MemError
instead of checking for NIL--actually, that's what I do do.)

Now.....where's LSC 3.0.....  What's the price for upgrading.....  So
many questions, so little time.
--
-Ray
([e-mail])


------------------------------

From: [e-mail] (Larry Rosenstein)
Subject: Re: Error Handling and Recovery (long reply)
Date: 12 Apr 88 00:36:22 GMT
Organization: Advanced Technology Group, Apple Computer

In article <[e-mail]>
[e-mail] (Richard Siegel) writes:
>
>Has anyone come up with a bulletproof error recovery scheme, to recover
>from things like disk and memory errors?

I think MacApp has an error recovery scheme that can be used to write
bulletproof programs, but it requires some work on the part of the
programmer.  There are many aspects to the error handling in MacApp, so
I will just outline them.

First, we implemented a an exception handling mechanism in Pascal.  The
programming model is that there is a stack of exception handlers.  A
call to the routine CatchFailures pushes a handler on the stack.  A call
to Success pops a handler off the stack.  The CatchFailures & Success
calls have to nest within a particular procedure.

If an exception occurs, then the program can call Failure.  This pop the
top handler off the stack, restores the necessary registers, and calls
the handler.  If the handler returns normally, Failure is called
automatically, further unwinding the stack.  The handler can also do a
non-local GOTO if it wants to continue processing.

The Failure calls takes 2 parameters a 2-byte error code, and a 4-byte
message.  These values are passed to the exception handler.  (This gives
a 3rd alternative for the handler; it can call Failure can pass
different parameters.)

In general, the message is used to indicate what operation failed, and
the error code to indicate why it failed.  The main event loop of MacApp
contains a handler that looks these values up in a set of tables,
displays and appropriate alert, and continues handling events.

A typical error alert in MacApp might read "Could not save 'Foo' because
the file is locked. Use the Get Info command in the Finder to unlock the
file."

The "save 'Foo'" part describes what failed, and is based on the mesage
value.  The "the file is locked part" is derived directly from the error
code, as is the last sentence.

We use a generic alert for all error messages, and substitute in the
strings.  This allows us to provide very detailed messages, instead of
just "Could not save the file."

>From the programmer's point of view all s/he has to do it check for errors.
There are not very many error codes that makes sense to report (others
are converted into a generic message), and MacApp generally takes care
of providing the right message values.

In order to encourage progammers to check for errors we supply
utilities. For example FailNIL takes a pointer or handle and calls
Failure(memFullErr, 0) if the parameter is NIL.  Similarly, FailOSErr
takes an OSErr parameter and calls Failure if it is non-0.

This leads to code such as: x := NewHandle(...); FailNIL(x); or
FailOSErr(FSWrite(...));  After a while you get in the habit of checking
for errors.

A recent article of mine talked about MacApp's memory management
strategy. Basically, we try to reserve enough memory in advance to
ensure that the program will be able to function, save documents, and
quit without bombing. This requires the programmer to tell MacApp the
amt of memory to reserve.

For disk errors, MacApp by default saves a document to a temporary file,
and only deletes the original if the save succeeds.  This requires the
programmer to tell MacApp the number of bytes needed to save the file.
MacApp will check to see if there is enough disk space, create the temp
file, tell the program to save into it, and rename the temp file to the
correct name.  It also copies the Finder information from the old file
so that the icon doesn't move, etc.

If there is not enough disk space to make a copy, then MacApp itself
will call Failure, and the user will be told that s/he is out of disk
space. There is one interesting situation.  There might not be enough
disk space to make a copy, but if the original was deleted first, there
would be.  In that situation, MacApp puts up an alert asking if it is OK
to delete the original file first.

MacApp also checks for other cases that happen in an environment with
file servers.  For example, before saving a file we check to see if the
modification date is the same as when we read the file.  If not, someone
else may be using the file, and the user is given a message.

If the user tries to revert and the file doesn't exists or the file type
has changes s/he also gets a message, and the revert is aborted.

We tested the error handling in MacApp by adding all the necessary
checks to 2 sample programs, and testing them as if they were real
products.  We didn't ship MacApp until these sample programs could pass
this stress test.

That's some of the highlights, if there are any questions let me know.

--
         Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 27-AJ  Cupertino, CA 95014
        AppleLink:Rosenstein1    domain:[e-mail]
        UUCP:{sun,voder,nsc,decwrl}!apple!lsr


------------------------------

From: [e-mail] (Jon Hueras)
Subject: Re: LSC and CODE resources
Date: 12 Apr 88 03:16:19 GMT
Organization: Symantec/THINK Technologies, Bedford, MA

In article <[e-mail]> [e-mail] (Larry Rosenstein)
writes:
>In article <[e-mail]> [e-mail] (Richard Siegel) writes:
>>
>>is on pages 9-13 to 9-15 of the user's guide. All the glue does is
>>place the handle to the code resource in ToolScratch and then jump
>>to the beginning of the real code.
>
>By the way, the article in the April MacTutor on floating windows talks about
>the use of ToolScratch by the Menu Manager and LSC.  It was wrong when it
>blames the Menu Manager for using the location.  ToolScratch is reserved for
>use by the Toolbox; its value is not preserved across calls to the ROM.
>
>--
>         Larry Rosenstein,  Object Specialist
> Apple Computer, Inc.  20525 Mariani Ave, MS 27-AJ  Cupertino, CA 95014
>        AppleLink:Rosenstein1    domain:[e-mail]
>        UUCP:{sun,voder,nsc,decwrl}!apple!lsr

I'd like to take exception to this line of reasoning. NOWHERE does it
say that ToolScratch is reserved for ROM use only. ALL it says is
exactly what you said: "its [sic] value is not preserved across calls to
the ROM." If you use the value the LSC code resource header puts in
ToolScratch as it is intended, you fetch the value immediately upon
entry into 'main' and pass it to 'RecoverHandle' to get a handle to the
resource so you can lock it. By the time you call RecoverHandle, you are
no longer depending upon the value of ToolScratch. No ROM calls
intervene, and so the value is unchanged when you get it.

The problem is that the Menu Manager, in using ToolScratch as parameter
storage (I forget for which one), is violating this rule to the hilt.
Who's to say what ROM calls a Menu DefProc may make before it ever gets
around to referencing this parameter. It just so happens that the
STANDARD Menu DefProc never calls a routine that affects ToolScratch;
but why should Apple, who has made it possible for OTHERS to write Menu
DefProcs of their own, then leave a gaping hole for them to fall into!

This is not the first time I have encountered this sort of thing. I once
discovered, inadvertantly, that the Finder uses Scratch20 as a
EventRecord in calling GetNextEvent. Scratch20 is another low-mem area
that falls into the same category as ToolScratch - it's not expected to
remain the same across ROM calls, but it is NOWHERE declared as reserved
for Apple use only. Although the Finder's usage conflicted with what I
wanted to do with Scratch20, my usage was in kind of a gray area and so
I backed off and did something else. But I did not fail to note that the
Finder's use of Scratch20 in this way potentially conflicted with the
legitimate use of it by other software, namely DAs!

Any call to GetNextEvent may result in the invocation of DA code if
GetNextEvent (via SystemEvent) determines that a particular event
belongs to a DA. If the DA tries to use Scratch20 in a legitimate way
(i.e., for temporary storage while doing something that doesn't involve
ROM calls), it's going to be awfully upset when it finally tries to get
at that EventRecord, which it has just munged when it wrote to
Scratch20.

However farfetched this particular example may seem, the moral remains:
in software, rules are NOT made to be broken.

As a historical note, the use of ToolScratch by LSC code resources is
strictly a vestigial feature from the days prior to the introduction of
inline assembly, which makes it totally unnecessary. We hesititate,
however, to take it out for fear of breaking other people's software
that may depend on it. We, at least, take our documentation seriously.

   Jon Hueras
   Symantec/THINK Technologies


------------------------------

From: [e-mail] (Charlie C. Kim)
Subject: Re: What hard disks does A/UX support
Date: 10 Apr 88 20:57:56 GMT
Organization: Columbia University


A Rodime 140 and theoretically the entire Rodime line should work just
fine as an A/UX only disk.  The A/UX generic SCSI driver seems to be
very good.  (The Rodmine 140 is slightly faster than the std. Apple 80MB
internal).  Unfortunately, the Rodime drivers do not support the
Macintosh II partition manager as defined in Inside Macintosh Vol. V,
thus you cannot take a parition for use under MacOS - don't even try!
Actually, the Apple MacOS driver almost works--reads seem reliable, but
writing is not :-).  This is probably true of most MacOS disk drivers
today (of course, it's possible that with some of the disks, the Apple
MacOS SCSI disk driver would work, but not on the Rodime at least).

Never run a SCSI driver that does not understand the IM Vol V notion of
partitions on a drive that is partitioned.  (You really have to work at
this though -- about the only way to get it on the disk is using dd :-).
 It will not work correctly.  Another warning, there is another
partition manager defined in Inside Macintosh Volume IV that is quite
different and incompatible with the one defined for macintosh II's and
used by A/UX.  (The sample SCSI driver from Apple deals with IM.IV
partitions).

The easiest way to setup a Rodime 140, is to just dd over the data from
a distribution 80MB and munge with the partition tables to get the extra
60 meg in.  To play things really safe, either kill the MacOS partition
or lock it with dp--leaving it around unlocked can cause problems.

My advice is to keep the changes as simple as possible.  I simply turned
off writes on the MacOS partition (with a copy of sash and utilities)
and reused the "Extra" partition at DPM 8 as a "user UFS partition"
containing the remainder of the space (physical: 125218@156368).
However, this does have one minor problem.  Disk partitions/slices under
A/UX (e.g. /dev/dsk/c0d0s0, s1, s2) are not "directly" mapped to the
partitions under the partitition manager. You use "pname" to define
mappings -- so be careful there.  You might find it simpler in the long
run to simply shuffle around the file systems so that you can have one
big A/UX partition--however, the problem here is knowing where to put
things.  The eschatology file system are presumably placed on the disk
in different physical locations to minimize the effects of any hardware
disk damage (of course, this didn't help me any -- my disk just went
under totally).

If you don't think you want to copy the entire disk and just want to get
things to the point where you can munge things around, the physical disk
layout is something like:
    <boot block>
    <partition blocks> [1 per partition]
    <MAC OS driver>
    <1st extra/Free parition>.. just dd from 0 to the physical partition
start of the first partition following the MacOS driver.  I am pretty
sure the dp size blocks are 512byte units, so you could setup for
running dp on a new disk by issuing the command "dd if=/dev/dsk/cXd0s31
of=/dev/dsk/cYd0s31 count=96" where X is the SCSI id of the original and
Y of the destination.  This will copy the MacOS driver too.  This is
just paranoia because I'm not sure what MacOS will do if it sees a disk
drive without a 'driver' on it.

In article <[e-mail]> [e-mail]
(Stuart Schmukler) writes:
>In prinicple the 'dp' utility can deal with any type of hard drive.
>The problems are:
>    Configuring and loading the Eschatology parts of A/UX
>    Loading the Eschatology parts of A/UX
>    Configuring the Mac partition
>    Loading the Mac partition
>and    making sure that the Mac OS respects the partition
>     (say during Erase Disk)
>
>SaS
>
>PS: Dealing with 'dp' is arcane. If I was clearer on the subject I'd
>write it up. We found that you had to check the System Admin man pages
>and the A/UX device drivers manual.

The easiest way to deal with these problems (as noted above) is to
duplicate the partitions from the distribution disk and play with them.
The only problem left is ensuring that MacOS respects the partitions: it
should if the MacOS driver you installed respects the Macintosh II disk
partition manager.  If it does not, then it will probably smash the disk
anyway.

I think the idea was to have the partitions generated from MacOS by a
vendor specific utility that reserves space for <n> (user specified)
partitions, creates any MacOS partitions you wanted, and installs the
driver.  dp could then be used to install the A/UX partitions.  Of
course, the problem is finding disk drivers that support the Mac II
partition manager.  Remember, it is important to note "dp" can't be
expected to initialize the disk correctly for MacOS because a vendor
specific driver must be installed if you are to use it under MacOS.

Suggestion for the next release of A/UX -- either make it easier to
build the default set of partitions (including MacOS partitions) via dp
or leave more slots in the standard distribution!  There's only two free
partitions--for really big drives, this really isn't enough.

Also, make the slice to partition mapping go in order or have some more
rigid mapping.  This would make me feel much safer.
--
Charlie C. Kim
User Services
Columbia University


------------------------------

From: [e-mail] (Hugh Daniel)
Subject: Problems with A/UX--NFS locking up
Date: 11 Apr 88 08:06:36 GMT
Organization: Nebula Consultants in San Francisco


  We have found that the Apple Ethernet card can not take the eight back
to back packets that our sun can send it.  This will make a mac act
strange when you have  a program that writes to a Mac/NFS disk, are the
program will lock up.  Yet if you try it by hand it will work as you can
not type 8k that fast.
  We fixed this by changeing our /etc/fstab entry on the *Sun* thus:
        grass:/u1 /u1   nfs rw,soft,bg,retrans=10,wsize=1024 0 0 The
"wsize=1024" is the magic that makes the packets small and far apart.
You will need to do this on ALL machines that write to the A/UX NFS file
system.
  I believe that this is the Apple (really 3Com) card being to slow.

                ||ugh Daniel [e-mail]                   Grasshopper
Group
--

        ||ugh Daniel
[e-mail] /wiscarpa%"[e-mail]" ...!hplabs!welll!hugh
These twisted geeks have Completely Lost their grip on Reality! -Duke


------------------------------

From: [e-mail] (n)
Subject: Re: Problems with A/UX--NFS locking up
Date: 11 Apr 88 17:20:59 GMT

We do a similar thing on our A/UX boxes when using Sun servers except we
use
                    .....,rsize=2048,wsize=2048

    Paul

--
Paul Campbell, UniSoft Corp. 6121 Hollis, Emeryville, Ca
    E-mail:        ..!{ucbvax,hoptoad}!unisoft!paul
Nothing here represents the opinions of UniSoft or its employees (except me)
"Nuclear war doesn't prove who's Right, just who's Left" (ABC news 10/13/87)


------------------------------

From: [e-mail] (Robert Nelson Gasch)
Subject: Re: 3D Graphic MANIPULATIONS.....
Date: 12 Apr 88 16:49:23 GMT
Organization: Carnegie Mellon University

I have easy 3d and it can not do what you require. Hope this eliminates
it and makes your search easier.
        ---> Rob


------------------------------

From: [e-mail] (Pawel Stefanski)
Subject: Bibliography support package wanted.
Date: 12 Apr 88 14:26:41 GMT
Organization: George Mason University, Fairfax, Va.

PACKAGE FOR BIBLIOGRAPHY SUPPORT WANTED!

I am looking for a program (hopefully compatibile with Microsoft Word)
which would provide me the kind of functionality offered by the 'refer'
package on SUN's: insert bibliography entry (author, title, abstract),
sorting / indexing, incorporating selected entries in one of standard
format into the documents, and so on - the more, the better. I will
appreciate any info, in case of interest - summarize to comp.mac.digest.
Thanks in advance,
--
Pawel A. Stefanski,         Phone [phone],
Machine Learning Laboratory,    Department of Computer Science,
George Mason University,        Fairfax, VA 22030.
===================================================================


------------------------------

From: [e-mail]
Subject: Enabling my Lisa to run Mac+ software
Date: 11 Apr 88 23:56:51 GMT
Organization: The City University of New York - New York, NY

Does anyone know how I can get my Lisa to run Mac+ software I been
trying for quite some time with no luck.  I've  been using Lisa Macworks
and the Macworks System  Diskettes, with no luck on running Mac+
software.  If  I load a diskette formated on a Mac+ I get not Macintosh
diskette intialize or cancel.  I can create files on the Lisa made with
MacDraw and look at them on a Mac+ or print them but I can't do the
reverse.  Can anyone help me out ? Any information would be greatly
appreciated.
--
-------
DCMCU@CUNYVM
Dana C. Murray   2nd Shift Supervisor
City University of New York Computer Center Telecommunication Dept.
555 WEST 57TH STREET 16 FLOOR
NEW YORK, N.Y. 10019   [phone]


------------------------------

From: [e-mail] (Dan Allen)
Subject: Re: Graphic window from MPW tool
Date: 12 Apr 88 18:28:59 GMT
Organization: Apple Computer Inc, Cupertino, CA

As a co-creator of the MPW Shell, I would like to set the graphical tool
controversy to rest.  Here is the scoop:

a)    Graphics instructions in MPW Tools are perfectly harmless.  They work
fine, as long as InitGraf(@thePort) is done right.  Since an MPW Tool
has its own A5 World, it has its own set of QuickDraw globals and can
draw to its heart's content.

b)    Where to draw?  Well, a tool can draw anywhere it likes to I suppose,
but it SHOULD draw in its own window, obviously.

c)    Tools & Windows.  A tool can have its own window.  MPW 2.0 ships
several tools which have their own windows, including Commando,
GetFileName, etc.  MPW Tool windows must be MODAL dialogs, however, to
work right currently.  You can also have nested Modal dialogs.

d)    Tools & Events.  Here is the crux of the problem.  Tools can have
their own MainEventLoop while in a ModalDialog, but tools cannot
currently have their own Modeless windows.  Why?  Well, the MPW Shell
currently does not have a good info passing mechanism for passing events
to tools that the Shell does not understand.  Such a mechanism is needed
in order to put up Modeless windows.

Remember that since MPW Tools are guests in the MPW Shell's heap that
they should not initialize the Window Manager or Menu Manager since they
are already up and working.

The warnings in the MPW 2.0 manual about graphical tools should have
been warnings about tools having Modeless windows.  As long as you can
constrain your tools to one or more Modal dialogs, then everything
should be fine.  To get an idea about what can be done, take a look at
Commando.

If you have more questions about MPW Tools and graphics, just ask.
--
Dan Allen
Software Explorer
Apple Computer

------------------------------

End of Usenet Mac Digest
************************
-------